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Amendments to the Description : 

The description of the specification has been amended as 
follows to copy the textual description of sections IV through 
VIII from page 7 to page 24 with reference to Figures 3-13 in 
the U.S. Provisional Application No. 60/228,772 from which this 
application claims priority and the entirety of which 
incorporated by reference as part of this application. 

A substitute specification is concurrently filed with this 
response to incorporate the following amendments. 

1. Please insert the following paragraphs at the end of 
page 2 of the specification under the subtitle "Brief 
Description of the Drawings": 

FIG. 1 is a schematic block diagram of a broadband system 
that includes a server and clients coupled by a network and can 
be used to implement the error correction techniques described 
in this application. 

FIG. 2A illustrates an implementation of the passive 
recovery mode of the hybrid ARQ/FEC algorithm. 



FIG. 2B illustrates an implementation of the active 
recovery mode of the hybrid ARQ/FEC algorithm. 





FIG. 3 shows a worst- 


-case retransmission scenario for the 


ARQ 


algorithm. 






FIG. 4 illustrates a 


relation between the virtual playback 


and 


the original playback 


schedule , 




FIG. 5 illustrates a 


worst-case retransmission scenario for 


the 


passive recovery mode 


of the hybrid ARQ/FEC algorithm. 




FIG. 6 illustrates a 


worst-case retransmission scenario for 



the active recovery mode of the hybrid ARQ/FEC algorithm. 
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FIG- 7 shows traffic overhead at the server link versus 



packet-loss probability. 






FIG. 8 shows the traffic overhead versus 


the 


number of 


receivers in the multicast session. 






FIG. 9 shows the traffic overhead versus 


the 


loss limit 



tolerable by the media. 

FIG. 10 shows the traffic overhead for parity group sizes 
ranging from 2 to 50. 

FIG. 11 shows receiver buffer requirement versus parity 
group size. 

FIG. 12 shows receiver buffer requirement versus packet- 
loss probability. 

FIG. 13 shows traffic overhead versus heterogeneous packet- 
loss probabilities . 

2. Please insert the following paragraphs beginning at page 
11, line 1: 

The following sections describe additional technical 
features of the error control in video distribution that 
combines both the ARQ and FEC error correction techniques. 

Existing studies on Internet video delivery usually use 
overall traffic overhead in the entire multicast tree as a 
metric for performance evaluation. This is motivated by the 
fact that the Internet is known to have limited bandwidth and 
hence protocols that can minimize overall traffic overhead are 
highly desirable. By contrast, overall traffic overhead is- less 
important in broadband residential network environments as the 
local or regional residential networks usually have relatively 
large bandwidth. The bottleneck is likely to be the trunk that 
connects the regional cluster with the central video server. 
This motivates us> to consider traffic overhead at the server- 



3 



I 



Attorney's Docket No.: 17329-004001 
Client Reference No.: 05F0298US 



side network connection instead of over the entire multicast 
tree . 

We define traffic overhead as the ratio between network 
traffic at the server link incurred in error recovery and the 
network traffic for normal video delivery. A traffic overhead 
of 0.1 means 10% additional network traffic incurred for the 
recovery of lost packets. Since the server link has only finite 
network bandwidth, too many traffic overheads will limit the 
scalability of the system. For simplicity, we ignore traffic 
overhead incurred by control packets such as NACK in the uplink 
from receivers to servers. This assumption is justified by the 
fact that retransmission requests are much smaller than 
retransmitted video packets. Hence, the downlink traffic volume 
will dominate the uplink traffic. 

Unlike Internet video distribution where the receivers are 
often conventional computers with lots of memory, set-top boxes 
with limited memory are usually used in residential 
applications. Therefore we use receiver buffer requirement as 
the second metric for performance evaluation. Since video data 
is a continuous-media that must be presented at a predetermined 
rate, memory buffers are needed at the receiver to absorb delay 
and delay jitters incurred in video packet delivery. If no data 
is available for playback due to network delay or packet loss, 
video playback will be stalled - also known as playback 
starvation. On the other hand, if too many packets arrive at a 
receiver too early, receiver buffer overflow will occur and 
likely results in packet dropping. Since a receiver must 
prefill some of its buffers before playback starts, a startup 
delay is incurred whenever a receiver joins a video multicast 
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session. As this startup delay directly affects system 
responsiveness, the receiver buffer requirement should not be 
too large even if memory is abundant. 

Let there be N receivers in a multicast session and let pi 
(Q^j^N) be the probability of packet loss experienced by 
receiver i. To model network delay, we let Tj be the average 
network delay, and Tj* (Tj*^0), Tj~ (Tj"<0) be the maximum delay 
jitters between receiver i and the server. Hence, the network 
delay experienced by a packet must be within (Tj+Tj*) and 
(Tj+Tj") . The delay and delay jitters can be obtained a priori 
if the network have quality-of -service support. 

At the receiver, let p max be the maximum tolerable packet- 
loss probability for the media (video) . We will use the term 
loss limit to refer to p ma x in the rest of the paper.. At the 
server, video packets of size Q s bytes are periodically 
multicasted with a period of T s seconds. Hence, if the video . 
bit-rate is R v bytes-per-second (Bps) , then T 5 =Q S /R V . Let T tr an be 
the transmission time for a video packet, i.e. the time for 
sending the entire video packet from the server memory onto the 
server-side network, with T t ran<T s - Let T sta rt be the time the 
server multicasts the first video packet for the multicast 
session. Then incorporating network delay, delay jitters, and 
transmission time, the arrival time at receiver i packet j 
(j =0,1,2...) denoted by Aj j is bounded by 

max{r^ + 7^ +,T 5 +T, +T~ J start }< A{ < T start +7^ + jT s +7^ , +7]* (1) 
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Note that we need the maximization because Ti^O. Knowing 
the above bounds , we can derive the performance metrics for ARQ, 
FEC, and the proposed hybrid algorithm in the following 
sections . 

ANALYSIS OF AUTOMATIC REPEAT REQUEST (ARQ) 



A. Traffic Overhead 

Assume that packet losses are independent and with loss 
probability pi, then the residual loss probability - the 
probability of an unrecoverable packet loss, after Kj 
transmission attempts is simply given by Pi— . To maintain video 
playback quality, we need to choose Kj such that the loss limit 
is not exceeded: 

Pf % */>max (2) 



Rearranging, we can then obtain Kj from 



K { > 



In p t 



(3) 



Given Kj, the expected number of transmissions for each 
video packet can be obtained from 



tiW-O-A)) (4) 
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Hence, the ratio of extra traffic overhead incurred 
(excluding the first transmission) in retransmission for 
receiver i is given by 



* traffic for retransmission ,»i ... 

h, = _ _ . = - - (5) 

traffic for data 1 



Finally, the traffic overhead at the server link is just 
the sum of traffic overhead for all receivers: 



^=1*. (6) 



r=0 



B. Receiver Buffer Requirement 

To determine the receiver buffer requirement, we let 
Larq (i) =Yi+Zj be the number of buffers (each Q s bytes) in receiver 
i, managed as a circular buffer. The receiver starts playback 
once Yj buffers are filled with video data. These Yj prefetched 
buffers are then used to absorb delay variations in packet 
arrivals to prevent video playback starvation (i.e. buffer 
underflow) . On the other hand, we reserve Z± empty buffers to 
cater for early-arrival packets to prevent buffer overflow. 

Under this model, video playback effectively starts at time 

* , which is the time video packet (Yj-1) arrives at receiver 
i. Hence, the playback time for video packet j of receiver i is 
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P/=Aj'-*+jT s 



(7) 



For simplicity, we assumed a constant playback time (T s ) for 
all video packets. This simplification can be removed to 
incorporate variable (but bounded) playback time or even 
variable-bit-rate video playback using techniques in [12] . 

To maintain video playback continuity, we must ensure that 

all video packets arrive before playback deadline. Formally, 

the arrival time for a video packet must be earlier than this 
playback time: 



Substituting the upper bound for Aj j and the lower bound for 
Pi j into (8), we can then obtain the condition for continuity as 



(8) 



max{^/}<min{f;. y } 
T*n +T tmn +jT s +T t +r/ < minj^" 1 +JT g ] 

= nrinU rH }+7T, 



(9) 



= t^+t^ +(7, -lfc + r f + rr +jT s 



Rearranging we can obtain Yj from 



TT-TT 



+i 



(10) 
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Similarly, to prevent buffer overflow, we need to ensure 
that an empty buffer is always available when a new video packet 
arrives. As the receiver buffers are managed as a circular 
buffer, we need to ensure that 



mini^^'- 1 }> maxfc + T s ) 

^ (11) 
T stan +T trm + +Z, - l)7i + 7; +7T > T stan +7^ + 0 + 1^ +T> +T+ 



Rearranging, we can then obtain Z±: 



T+-T~ 

Zi >^—^ + \ (12) 



Hence, the total number of receiver buffers needed for 
receiver i is: 



To incorporate the effect of retransmission, we note that 



each retransmission attempt incurs a maximum additional delay of 



Ttran 


+ T wa it + Ti + Ti 


+ , where T wa it is the retransmission timeout (Fig. 


3) . 


Since at 


most Ki transmissions (including retransmissions) 


are 


attempted 


for delivering a video packet, the upper bound for 



the arrival time of packet j of receiver i is modified to 



a( < (T stan +r frflB +jt, +7; +t; + )+(/: i . -1^ +T wail +t, +t;) <m) 
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where the first term is the worst-case delay incurred in 
the first transmission and the second term is the worst-case 
delay incurred in the next (Kj-1) retransmissions. 

Again, let there be L A rq (i) =Yj+Zi receiver buffers, and 



playback starts after Yi buffers are filled with video data 


Now 


as the packet-loss probability is non-zero, it is possible 


that 


some of those first Yi packets are lost and requires 




retransmissions. In particular, if video packet (Yi=l) is 


lost, 


the prefetch process (and hence playback) will be delayed. 


To 


avoid unnecessary delay, the receiver starts playback when 


the 


expected arrival time for packet (prefetch process (and hence 



playback) will be delayed. To avoid unnecessary delay, the 
receiver starts playback when the expected arrival time for 
packet (Yj-1) 

P°=4^7,-l)T, (15) 



is reached, regardless of whether the packet has physically 
arrived or not (i.e. due to loss or delay jitter) . Hence in 
general, we have 

ZV=4° + (lW-l)7i 06) 



Using the continuity condition, we can obtain Yj from 
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max{^}£min{p ( '} 

T^, +T lnn +jT s +7] +T+ +{K t -ifr^+T^+T.+T?)* min{^° + {7, +j-l)T s } 

*T M +T Bm +T l +Tr+{Y l +j-\)r s 

(17) 



Rearranging, we then have: 

v ^ {k, -\jT trm +tv, +Ti + r/K(r; -r,-) 



Compared to the case without packet loss (c.f. Eg. (10)), 
more buffers are needed to absorb the extra delay incurred in 
retransmissions . 

Similarly, to prevent buffer overflow, we need to ensure 

that : 



min{^ + ^}^ m ax{^ y+7 i} 
T start +T tran +U + Yi + Z, -1)7", +T> +?T * max^ 0 +fc +jts +^} (19) 



Rearranging, we can then obtain Zj as well: 



(20) 



Note that Zj is the same as the case without packet loss in 
(12) . This is because retransmissions make packets arrive only 
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later but never earlier. Summing (18) and (20) we can then 
obtain the receiver buffer requirement for receiver i: 



+ 



+ 2 



(21) 



If the network delay and delay jitters are known a priori, 
then the retransmission timeout T wa it can simply be set to equal 
to the maximum network delay (Tj + Tj + ) and (21) can be 
simplified to 



+ 2 



(22) 



As an example, using the parametric values in Table 1, the 
buffer requirement as calculated from (22) will be 41 units. As 
each unit stores a packet of size 1024 bytes, total buffer 
requirement would be 41KB. 

Note that in practice, one would implement the receiver 
such that NACK is sent as soon as a gap in sequence number is 
detected. However, the time to detetct such a gap depends on a 
number of parameters, namely packet size, video bit-rate, 
network delay jitter, and the extent of burst losses. Hence 
without resorting to specific parameter ranges, it would be 
difficult (if possible) to derive a general formula for the 
delay incurred in detecting a sequence-number gap. For special 
cases where gap-based detection delay is known to be shorter 
than the maximum network delay, one can simply replace T wait with 
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the appropriate formula for more accurate results. For 
simplicity, we will assume T wa it = (Tj+Ti + ) in the rest of the 
paper. 

C. Server Buffer Requirement 

At the server, buffers must be allocated to store outgoing 
video packets temporarily to support retransmissions. To 
determine the amount of additional buffer needed to support 
retransmission, we notice that the n th (n=l, 2, ...Kj-1) NACK for a 
transmitted video packet will arrive at the server at most 

K^^T^T^T*) (23) 



seconds after the first transmission attempt (c.f. Fig. 3), 
Hence, the maximum buffer-occupation time for a video packet is 



simply given by ' . Assuming that video packets for 
transmission are generated at the same rate as consumption, i.e. 
one packet per T s seconds, the number of video packets generated 

r K >~ ] 

during this duration is then given by 



(24) 



To cater for the requirements of all clients, the amount of 
buffer required for a server to support retransmission for one 
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multicast video stream would then be the maximum among all 
clients : 

Barq = Qs maxfo I / = 0,1, ...,(*-!)} (25) 



ANALYSIS OF FORWARD ERROR CORRECTION (FEC) 

In FEC, redundant data are introduced into the data stream 
in the form of redundant packets. Specifically, for every D 
video packets, R redundant packets are appended for transmission 
to the receivers. These R redundant packets are computed from 
the D video pockets using erasure-correction codes such as 
parity codes, or Reed-Solomon codes to form a parity group [13] . 
As R extra redundant packets are transmitted for every parity 
group, the packet inter-departure time at the server must be 
shortened to maintain the original video bit-rate. The new 

f 

inter-departure time s can be obtained from 

f s = T s — — (26) 
s D + R } 



Note that while the packet inter-departure time is 
shortened, the average rate at which video packets are 
transmitted remains the same. The extra transmissions are 
redundant packets computed from a parity group of video packets. 

A. Traffic Overhead 
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With R redundant packets, a receiver can correctly recover 
all D all video packets as long as no more than R packets are 
lost within the same parity group. However, in the event that 
more than R packets are lost, a decoding error [13] will occur. 
In the worst case, all D video packets will be lost. Hence, the 
upper bound for the residual loss probability given by 



d+r fn4.j?\ 

^-z t knr (27) 



On the other hand, if the erasure-correction code employed 
is systematic, i.e. the D video packets are not modified during 
the encoding process, then the residual packet-loss probability 
will be smaller. Let there by k lost packets among the D video 
packets and R redundant packets. Then on average 



k— — (28) 
D + R 



Of the lost packets will be video packets. As there are D 
video packets, the resultant loss probability for video packets 
given there are k losses is simply equal to 



*^-.±— *_ (29) 
D + R D D + R 



Hence, we can obtain the residual loss probability by 
conditioning on k: 
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D+R 



1-S 



k 



D + R 



(30) 



To maintain a residual loss probability of no more than 
Pmax/ we need a redundancy of at least 

/? F£C =min{/?|^<p raax ,V/} (31) 



Using a redundancy of Rfec/ the traffic overhead at the 
server link can be obtained from 

R 

H FEC = (32) 



Note that unlike ARQ, traffic overhead incurred by FEC is 
fixed irrespective of the number of receivers in the system. 

B. Receiver Buffer Requirement 

To determine the receiver buffer requirement, we again let 
Lfec (i) =Yi+Zj be the number of buffers (each Q s bytes) in receiver 
i and assume playback starts once Yj buffers are filled with 
video data. However, as some of the packets are redundant 
packets, these redundant packets are not "played back" ir; the 
usual sense. In particular, the redundant packets will be used 
for erasure correction if there are packet losses; or discarded 
otherwise. To account for this, we create a virtual playback 
schedule where the "playback" duration of a video packet or a 
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T 

redundant packet is s rather than T s (Fig. 4) . Under this 
virtual playback . schedule where redundant packets are being 
consumed by the receiver just like normal video packets, all 
(except the first video packet in a parity group) video packets' 
playback deadlines are pushed forward and continuity in this new 
schedule implies continuity in the original schedule. 

Formally, the video playback starts at time ^ , which is 
the time video packet (Yj-1) arrives at receiver i. Hence the 
playback time for video packet j is 

P/=A*>- ] +jT s (33) 



To maintain video playback continuity, we must ensure that 
all video packets from a parity group arrive before the playback 
deadline of the first packet in the same parity group is 
reached 3 . For example, let packet j be the next packet for 
playback and it is lost in transit. In the worst case, this 
packet will be the first packet of a parity group and we need 
the entire group to recover it. Since packet (j+R+D-1) would be 
the last packet in the parity group, we need to ensure that it 
arrives before the playback deadline for packet j : 

A J+*+o-x< p j (34) 
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Substituting the upper bound for Ai^"^" 1 , and the lower 
bound for Pj j into (34) we can then obtain the condition for 
continuity as 

max^/^-^min^} 
T~n +T tm +0+^+£>-l)f s +7; +7/ Sitiin^' 1 +jf s } 

= mT\[i r '- l }+jf s 

= T stm +T tra „ +fc -\f 5 +T i+ T~ +jf s 



Rearranging gives the requirement for Yj as 



(36) 



Similarly, we can obtain Zj using the same derivations as in 
Section V-B: 



[t*-t~) 



(37) 



The total receiver buffer requirement for receiver i is 
just the sum of Yj and Zji 



L rec (/) = 2 



ir-T-)' 



+D + R + ] 



(38) 



C. Server Buffer Requirement 
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Unlike ARQ, additional server buffers are not required to 
support retransmissions. However, depending on the erasure- 
correction code employed and the way the code is computed, 
additional buffers may be required to support encoding. 

We first consider the worst-case scenario where redundant 
packets are computed on-the-fly. Additionally, we assume that 
video packets of a parity group must all be available before 
encoding. Then for a system with D video packets and R 
redundant packets per parity group, the server will need to 
allocate (D+R) buffer units for encoding. Hence the amount of 
buffer required for one multicast video stream is 

B FEC ={D+R)Q S (39) 



This additional buffer requirement can be reduced in two 
ways. The first way is to use special erasure-correction codes 
that process video packets sequentially. For example, the 
parity coding scheme for R=l can be computed on a packet-by- 
packet basis. Only one packet's worth of buffer is required to 
store the intermediate computation results while buffers for 
transmitted video packets can be released immediately. This 
translates into a buffer requirement of only one packet per 
stream (i.e. B F ec=Qs) - 

The second way is to use pre-computed redundant packets. 
For example, the redundant packets can be computed beforehand 
and stored along video data in the disks. In this way, no 
encoding needs to be performed and hence no additional buffer is 
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required. The tradeoffs are overheads in disk storage and disk 
I/O bandwidth. 

ANALYSIS OF HYBRID ARQ/FEC 

A. Passive Recovery 

In passive recovery, the probability of a lost packet being 
unrecoverable by FEC is given by (30), i.e. the residual loss 
probability gj. The amount of traffic overhead incurred by ARQ 
would then be given by (5) and (6), with pi replaced by the 
corresponding residual loss probability gj. Hence, given a 
redundancy of R, the traffic overhead can be computed from 



lnp l 



D |-0 1 y_i 



where K i = 



In £, 



(40) 



The level of redundancy R essentially determines how many 
losses are to be recovered through FEC, while the rest will be 
recovered by ARQ. The key is that traffic overhead incurred in 
FEC is fixed irrespective of number of receivers while overhead 
for ARQ increases with number of receivers. Hence, for systems 
with many receivers, the extra overhead in increasing R can be 
more than offset by the corresponding reduction in ARQ overhead. 
From (31), the maximum amount of redundancy needed is Rfec- 
Hence the optimal amount of redundancy for hybrid ARQ/FEC, 
denoted by Rhybridf required to minimize the traffic overhead as 
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given by (40) can be determined by choosing Rh V brid=0/ 1; • r Rfec 
such that Hybrid (Rhybrid) is minimized. 

Note that this hybrid ARQ/FEC algorithm reduces to ARQ when 
Rhvbrid=0 and reduces to FEC when Rhvbrid^R fec • Furthermore, as we 
choose Rhvbrid such that H hV brid (Rhvbrid) is minimized, this hybrid 
algorithm performs at least as good as either ARQ or FEC alone. 

At the receiver, we need to reserve buffer space not only 
for erasure correction; but also for retransmissions as well. 
Fig. 5 depicts the worst-case scenario for retransmitting 
packets not recoverable by erasure correction. Since 
retransmission starts after the entire parity group is received, 
the receiver can send a single request back to the server for 
all lost packets in the parity group. If one or more 
retransmitted packets are lost again, the next round of 
retransmission starts immediately after the last retransmitted 
packet has timed out in the current round. This process repeats 
until either all packets are received or the maximum number of 
retransmission attempts is reached. 

At the server, we assume that retransmitted packets are 
sent at normal data rate, i.e. with a transmission time of T t ranr 

f 

and an inter-packet time of (equation) . The server s . The 
server deliberately smooths out the retransmission traffic to 
avoid causing congestion in the network or a t the receiver. 

As the receiver will attempt at most (Kj-1) retransmission 
for a video packet, the wor;st-case delay incurred for receiving 
any packet within the parity group is given by see (Fit. 5): 
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[(D + *-l)f,+ 



(41) 



where the first term is the worst-case delay incurred in 
waiting for the whole parity group to arrive and the second term 
is the worst-case delay incurred in those (Kj-1) retransmission 
assuming all D video packets are lost in every transmission (and 
retransmission) rounds except the last one. Hence, the upper 

a! 

bound for ^ becomes: 



Together with the continuity condition in (8) and (9), we 
can obtain Yj from: 



Substituting (42) for the L.H.S. and (16) for the R.H.S. we 
can then obtain the requirement on Yj: 



Aj<(T stan +jf s +(D+R-\)T s + 



T trm +t,+t;)+{k, -\i(D-\)f s +7^ +2(7; + 



r;j) (42) 




(43) 



-\j(p-\f s +7^+2(7; +t;))+(t; -t- 



+ D+R 



(44) 



Again as the lower bound for 



is not changed, the 



requirement for Zj is the same as FEC: 
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(t+ -T~) 



(45) 



The receiver buffer requirement for receiver i is then 
given by 



^hybrid '(') — 



1 ~ 1 + £> + /? + ! (46) 



At the server, two types of additional buffers are needed 
to support passive recovery. First (D+R) buffers are needed to 
support erasure-correction encoding. Second, buffers holding 
transmitted packets cannot be released until the (i.e. Kj-1) 
retransmission request arrives. According to Fig. 5, the client 
starts requesting retransmission after the whole parity group is 
received, i.e. after a maximum delay of (c.f. Fig. 5). 



? = (z>+*-i)r ff +r^ + 7;+7;* 



(47) 



Hence, the delay for the first retransmission request to 
arrive at the server is at most 



(48) 



Similarly, delay for the n th retransmission request to 
arrive is at most 
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r: = r t + (r, + T* )+ (at - lfe + r; + (D - \)f s + T lrm+ T i+ T:) (49) 



Given that new groups of D packets are being generated at a 
rate of one group per DT S , there will be at most 



(50) 



groups co-existing simultaneously for a multicast video 
stream. Together with redundant packets, each parity group 
requires (D+R)Q S bytes of buffer and hence the total buffer 
requirement can be obtained from 



B^^QAD + Rl-^zrl (51) 



Active Recovery 

With active recovery, retransmission is needed only if 
there are more than R lost packets because otherwise the lost 
packets would be recoverable by erasure correction already. For 
example, if there are exactly m packets lost in a parity group, 
only (m-R) of the m lost packets need to be retransmitted. On 
the other hand, retransmission can start as soon as the receiver 
detects the loss of the (R+l) th packet without waiting for the 
whole parity group to arrive. We assume that given there are m 
(m>R) packets lost in the first transmission of a parity group, 
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the receiver will request retransmission for the lat (m-R) of 
these lost packets. As each one of these (m-R) packets will be 
retransmitted for at most (Kj-1) times, the probability that a 

retransmitted packet cannot be recovered is equal to ^ l 
Hence, the probability that w of the (m-R) packets being 
recoverable by retransmission is given by 



w,(>v) = 



>i (52) 



Using this equation, we can compute the conditional 
probability of having k(m^k^R) lost packets in the parity group 
after retransmissions given there are m lost packets from 



<D ( (*,/w) = «/,(*-/?) = 



(53) 



Now, the probability that there are exactly m packets lost 
in a parity group is given by 



Pr{/w lost in a parity group} = 



(D + R 



v m J 



m /i _ \D+R-m 



PT 0-/»,) 



(54) 



Therefore we can obtain the unconditional probability of 
having k (k^R) lost packets after retransmission from 
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D+R 



<!>,(*) = ^<lv(*,ro)Pr{/n lost in a parity group}, k > R 

m ** (55) 

Now if k>R, then erasure correction will not succeed. 
Assuming the erasure-correction code is systematic, then the 
loss probability for video packets in a parity group is given by 
(29) . Hence, we can obtain the residual loss probability by 
conditioning on k: 



D+R K 

Ett^'W (56) 



To determine the traffic overhead, we first need to find Kj. 
Given R and the loss limit p ma x; we can compute the minimum value 
for Kj such that the condition 



is satisfied. Once Kj is known, we can obtain the amount of 
traffic overhead incurred in retransmission for each lost packet 
from 



A^z^ro-A)) (58) 
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Hence given there are m(m>R) lost packets in a parity 
group, the expected amount of traffic overhead incurred is given 
by (m-R)hj. The average amount of traffic overhead incurred by 
all N receivers can then be obtained from 



D ,=0 IF!=»/l+) 

N-\ D+R /r,-i 



1 /V-l U+K ___ 



v m J 



- 1 % X 



m , 



(59) 



and the total traffic including redundancy is 



+ (60) 



To minimize the total server bandwidth requirement, one can 
choose Rhvbrid-Or If -r Rfec such that HhybridRhvbrid is minimized. 

To determine the receiver buffer requirement for video 
playback continuity, we note that the receiver starts requesting 
retransmission as soon as (R+l) packet losses are detected. 
Hence, the worst-case arrival time (i.e. after .(Kj-1) 
retransmissions) for packet x must be larger than y if x>y. In 
the worst-case scenario, all packets (except those not 
retransmitted) must have arrived (or will never arrive) by the 
time the last packet of the parity group arrives after (Kj-1) 
retransmissions (see Fig. 6) . Therefore the packet arrive time 
is bounded from above by 
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Af<i? stan +jf s + (D + *-l)f, +7^ + 7] -1)^+2(7; +7;*)) 



(61) 



Using similar derivations, we can obtain Yj as 



^ {k, -\jf s +T lnm +2fc +t;))+(t; -T~) ]DiR 



(62) 



And Zj as in (45) . The total receiver requirement becomes 



" fc -lXfi +r- +2fc -r) ' 



r* -7" 



+ £> + /? + ! (63) 



To determine the amount of server buffer required to 
support active recovery, we notice that delay for the n th 
retransmission of the last packet in a parity group is given by 



if = + (t; + t; ) + («- i)(r (raB + 2(7; + t; )) 



(64) 



Using derivations similar to Section VII-A, the server 
buffer requirement can be found to be 



(65) 



PERFORMANCE EVALUATION 
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In this section, we compare the performance of the proposed 
hybrid ARQ/FEC algorithm with ARQ and FEC with respect to 
various system parameters. The values of the system parameters 
used for numerical evaluation are summarized in Table 1. 

A. Traffic Overhead versus Packet-Loss Probability 

Fig. 7 plots the traffic overhead at the server link versus 
packet-loss probabilities ranging from 0.001 to 0.1. The main 
observation here is that ARQ incurs far more traffic overhead 
than either FEC or hybrid ARQ/FEC for both 100 and 1000 
receivers. This illustrates the well-known scalability problem 
in using ARQ for multicast data distribution. Secondly, we 
observe that both variants of the proposed hybrid algorithms 
performs equal to or better than the FEC algorithm, which in 
turns outperform ARQ by a large margin. Thirdly among the two 
hybrid variants, active recovery performs best. This result 
shows that the proposed hybrid algorithm is superior to both ARQ 
and FEC for a wide range of packet-loss probabilities. 

B. Traffic Overhead versus Number of Receivers 

Fig. 8 plots the traffic overhead versus the number of 
receivers in the multicast session. We observe that ARQ 
performs better than FEC when the number of receivers is smaller 
than 32, and FEC performs better otherwise. On the other hand, 
the proposed hybrid algorithms perform equal to or better than 
both ARQ and FEC, with active recovery performs slightly better. 
Hence, the proposed algorithm not only can be scaled up to serve 
a large number of receivers, but also can maintain a low traffic 
overhead when the number of receivers is small. 
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C. Traffic Overhead versus Loss Limit 

Fig. 9 plots the traffic overhead versus the loss limit 
tolerable by the media. The result shows that FEC performs 
better than ARQ, and the hybrid algorithms perform even better 
for a wide range of loss limits. Once again, the active 
recovery scheme performs slightly better than the passive 
recovery scheme due to the better utilization of the redundant 
packets . 

D. Traffic Overhead versus Parity Group Size 

Fig. 10 plots the traffic overhead for parity group sizes 
ranging from 2 to 50. Obviously, ARQ is independent of the 
parity group size and hence remains constant in this figure. 
For FEC and the hybrid algorithms, increasing the parity group 
size generally reduces the amount of traffic overhead at the 
server. This is expected because the traffic overhead is 
directly proportional to the ration R/D as expressed in (32), 
(40) and (60) . However, the parity group size also affects the 
receiver buffer reguirement as well (Fig. 11) . Interestingly, 
increasing the parity group size does not necessary raise the 
receiver buffer reguirement. In some cases, like going from 
D=10 to D=12 in Hybrid-Passive with 100 receivers, the buffer 
requirement decreases substantially for the increase in parity 
group size. This observation is explained by the fact that the 
increase in parity group size results in a reduction in the need 
for retransmission. For the Hybrid-Passive with 100 receivers 
case, increasing D=10 to D=12 also increases the optimal amount 
of redundancy from R=l to R=2 . This further decreases the 
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maximum number of transmissions needed from K±=2 to Kj=l (i.e. 
FEC only) , which reduces the receiver buffer requirement 
substantially. 

E. Receiver Buffer Requirement versus Packet-Loss 
Probability 

Fig. 12 plots the receiver buffer requirement versus 
packet-loss probabilities ranging from 0.001 to 0.1. The result 
shows that FEC has the lowest receiver buffer requirement under 
the operating conditions as set forth in Table 1. ARQ generally 
requires more receiver buffers than FEC and the hybrid 
algorithms except for loss probabilities below 0.015 and over 
0.07. As we choose the hybrid algorithms' operating parameters 
to minimize traffic overhead, the receiver buffer requirement 
fluctuates between the ARQ curve and the FEC curve for different 
loss probabilities. If it is desirable to incorporate the cost 
of receiver buffers, we can modify the optimization procedure in 
choosing R so that an integrated objective function taking into 
both traffic overhead and buffer cost is optimized, rather than 
based solely on H hvbr i d (R). 

F. Server Buffer Requirement 

The server buffer requirement plots (not shown) are similar 
to the receiver buffer requirement plots. This is because due 
to retransmissions, longer buffer-holding time at the receiver 
also implies longer buffer-holding time at the server. With the 
system parameters in Table 1, the server buffer requirements for 
all cases (i.e. ARQ, FEC, Active and Passive Hybrid ARQ/ FEC) 
remain below 200 KB per stream for a wide range of parameters 
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(N=1„.100Q. pi=0 . 0...0. 1) . Therefore a 100-stream server would need 
no more than 20MB of memory for error-control. Given the rapid 
price drops and capacity gains in memory chips , we can conclude 
that server buffer requirement will not be a significant factor 
in selecting error-control algorithms. 

G. Heterogeneous Packet-Loss Probabilities 

So far, the results are computed with all receivers having 
the same packet-loss probability. In practice, different 
receivers will likely experience different packet loss 
probabilities because of different network conditions, different 
processing power, etc. To evaluate the performance of the 
proposed hybrid algorithms under heterogeneous receiver 
conditions, we set the receivers' packet-loss probabilities 
according to a uniform distribution over a range P L and P H - 
Specifically, the packet-loss probability for receiver I is 
given by 

P i =P L^ P H- P i)-^Z\ (66) 



where P L and P H is defined by the average packet-loss 
probability P M and the range factor y. 

P L =Py0-r) (67) 
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Setting P M =0.25, we plot the traffic overhead for O^y^l in 
Fig. 13. As expected, ARQ is relatively insensitive to receiver 
heterogeneity. By contrast, FEC's performance deteriorates for 
increasing receiver heterogeneity because a fixed amount of 
redundancy is used for all receivers. The proposed hybrid 
algorithms have lower traffic overhead than both ARQ and FEC for 
the entire spectrum of O^y-1- Again, the active recovery mode 
performs better than the passive recovery mode due to the better 
utilization of redundant packets. 
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